Methods and apparatus to manage application updates in a cloud environment

ABSTRACT

Methods, apparatus, and systems to manage application updates in a cloud environment are disclosed. Disclosed example methods include determining that a collector in a collector bank is available to process a task, the task to at least one of request an application version or request an application update and sending, the task from a task queue to the collector to determine which compute node is to execute the task. Disclosed example methods also include enqueuing the task on a target queue based on a routing key assigned to the task by the collector, the routing key to specify the compute node to execute the task, and sending the task to the compute node associated with the target compute node queue.

RELATED APPLICATIONS

Benefit is claimed under 35 U.S.C. 119(a)-(d) to Foreign applicationSerial No. 810/CHE/2015 filed in India entitled “METHODS AND APPARATUSTO MANAGE APPLICATION UPDATES IN A CLOUD ENVIRONMENT”, on Feb. 19, 2015,by VMware, Inc., which is herein incorporated in its entirety byreference for all purposes.

FIELD OF THE DISCLOSURE

This disclosure relates generally to virtualized computing environments,and, more particularly, to managing application updates in a cloudenvironment.

BACKGROUND

“Infrastructure-as-a-Service” (also commonly referred to as “IaaS”)generally describes a suite of technologies provided by a serviceprovider as an integrated solution to allow for elastic creation of avirtualized, networked, and pooled computing platform (sometimesreferred to as a “cloud computing platform”). Enterprises may use IaaSas a business-internal organizational cloud computing platform(sometimes referred to as a “private cloud”) that gives an applicationdeveloper access to infrastructure resources, such as virtualizedservers, storage, and networking resources, By providing ready access tothe hardware resources required to run an application, the cloudcomputing platform enables developers to build, deploy, and manage thelifecycle of a web application (or any other type of networkedapplication) at a greater scale and at a faster pace than before.

Deployment tools currently in use are usually a patchwork of varioussoftware products from different vendors and/or homegrown solutions.Such tools are generally process-driven with heavy reliance on customscripts and property files. Traditional deployment tools are also notconfigured for scaling with cloud computing platforms that dynamicallyprovision virtual computing resources.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example system constructed in accordancewith the teachings of this disclosure for managing application updatesin a cloud environment.

FIG. 2 is a block diagram of an example data compute node that mayexecute applications to be managed by the example system of FIG. 1.

FIG. 3 is a flowchart representative of example machine readableinstructions that may be executed to implement the example system ofFIG. 1 to manage application updates of the data compute nodes.

FIG. 4 is a flowchart representative of example machine readableinstructions that may be executed to implement the example messagebroker of FIG. 1 to manage tasks.

FIG. 5 is a flowchart representative of example machine readableinstructions that may be executed to implement the example collector ofFIG. 1 to process tasks and responses from the example message broker ofFIG. 1.

FIG. 6 is a flowchart representative of example machine readableinstructions that may be executed to implement the example messagebroker of FIG. 1 to request that the example collector bank of FIG. 1deploy an additional collector or terminate an existing collector.

FIG. 7 is a flowchart representative of example machine readableinstructions that may be executed to implement the example agents ofFIG. 1 to proactively send version control responses to the messagebroker of FIG. 1.

FIG. 8 is a block diagram of an example processor platform capable ofexecuting the example instructions of FIGS. 3, 4, 5, 6, and/or 7 toimplement the example system of FIG. 1.

FIG. 9 is an example performance comparison graph 900 depicting aperformance of the system 100 of FIG. 1 for determining versions ofapplications executing in a deployment environment (e.g., the deploymentenvironment 104 of FIG. 1) relative to a virtual machine configurationmanager.

Wherever possible, the same reference numbers will be used throughoutthe drawing(s) and accompanying written description to refer to the sameor like parts.

DETAILED DESCRIPTION

Managing applications in a cloud environment is a challenging task,especially when application updates are required to protect data computenodes (DCNs) in the cloud environment from security vulnerabilities.Because many modern cloud environments include many heterogeneoussystems (e.g., a variety of types of DCNs, a variety of operatingsystems, etc.), managing application updates is a complex and timeconsuming task. For example, different DCNs and/or operating systems mayhave different communication capabilities, communication protocolrequirements, etc. Additionally, within the cloud environment, DCNs maybe deployed dynamically as more services are required by users of thecloud environment. As the number of DCNs in the cloud environment grow,manual and one-to-one (e.g., using multithreading to communicate witheach DCN, etc.) application updating becomes increasingly unfeasible.

As disclosed in detail below, a cloud administrator and/or a developermay, via a user interface, create version control tasks to be performedby agents installed on DCNs in the cloud environment. in examplesdisclosed herein, a message broker and collector(s) are deployed tomanage the version control tasks so that target DCNs process the versioncontrol tasks in parallel. The message broker and the collector(s) aresometimes referred to as “middleware” because the message broker and thecollector(s) facilitate communication between the administrator and/or adeveloper and the DCNs. Example version control tasks include a taskrequesting the version of one or more applications executing on a DCNand/or a task requesting one or more the applications be updated, etc.The user interface may also allow the cloud administrator and/or adeveloper to view the applications running on DCNs in the cloudenvironment and to view the latest known application version (e.g.,updated after a version control task is performed to obtain applicationversions).

As disclosed in detail below, to manage application updates in a dynamiccloud environment, example message brokers and example collectors may beloosely coupled to control the flow of version control tasks requestedby the cloud administrator and/or developer. In some examples usedherein, loosely coupled communication refers to asynchronouscommunication where the message broker(s) and the collector(s) executeindependently of each other (e.g., a change in how a message brokerhandles a version control task does not change how a collector in thecollector bank handles the version control task and vice versa).

An example message broker maintains queues to manage version controltasks received from the administrator and/or developer, sent to and/orreceived from the collector bank(s), and/or sent (e.g., directly orindirectly) to the DCNs. The example message broker also maintains aqueue for version control responses received from the DCNs. Exampleversion control responses include responses received as a result of aversion control task and messages proactively generated by agentsexecuting on the DCNs. In some examples, the message broker(s) and thecollector bank(s) have a many-to-many communication relationship (e.g.,all message brokers are in communication with all collector banks). Insuch examples, the message broker may maintain a single queue forversion control tasks and a single queue for the version controlresponses regardless of the number of collector banks the connected tothe message broker. In addition, the example message broker may maintaina queue for each DCN connected to the example message broker.

As disclosed in detail below, an example collector bank executes one ormore example collectors to process version control tasks based on rulesand/or policies set by the administrator and/or developer. In someexamples, a collector signals (e.g., notifies the message broker) whenit is available to process a version control task or a version control.response. Upon receiving a version control task, the example collectordetermines which DCN(s) is/are to receive the version control task andgenerates a targeted version control task. In some examples, to generatethe targeted control task, the controller attaches routing key(s) to theversion control task. In some examples, the DCN(s) to receive theversion control task may be specified in the version control task. Forexample, an administrator and/or a developer may specify a particularDCN and/or a particular group of DCNs to execute the version controltask. Additionally or alternatively, the example collector maydetermine, based on policies specified by the administrator and/ordeveloper, which DCNs are to execute the version control task. In someexamples, policies may be based on the criticality of an applicationupdate, a tune required to apply the application update, the criticalityof a particular DCN, etc. For example, a policy may state that certainDCNs are to receive only critical updates (e.g., critical applicationsthat should not be interrupted often, etc.).

In some examples, the collector bank dynamically manages the collectorsin the collector bank. From time to time, the example message broker mayrequest that an additional collector be deployed or that an existingcollector be terminated. For example, if the lengths of the versioncontrol task queue and the version control response queue maintained bythe message broker satisfy (e.g., are greater than or equal to) athreshold for a period of time, the example message broker may requestthat an additional collector be deployed. As another example, if theversion control task queue and the version control response queuemaintained by the example message broker are empty or nearly empty for aperiod of time, the example message broker may request that a collectorbe terminated. In some examples, the period of time may be measured incomputer cycles. In some examples, the collector bank may proactivelydeploy and/or terminate collectors. For example, the collector bank mayterminate a collector if the cumulative idle cycle time of thecollectors satisfies (e.g., is greater than or equal to) a threshold.

As discussed in further detail below, DCNs include an agent to respondto version control tasks. In some examples, the agent is executed in theDCN (e.g., as an application in the DCN, etc.). Additionally oralternatively, the agent may be executed separate from the DCN, buthaving sufficient permissions to process the version control tasksrelated to the DCN. A version control task may request the version of aparticular application installed on the DCN or may request the versionsof one or more of the applications installed on the DCN (e.g., acontainer may have a single application while a VM may have multipleapplications installed). In response to the version control taskrequesting the version(s) of application(s) installed on the DCN, theexample agent sends a version control response to the message brokercontaining the installed version of one or more applications.Additionally, the example version control task may request that aparticular application be updated. In response to such requests, theexample agent retrieves and/or requests the appropriate file(s) from anapplication repository that stored application updates and patches. Theexample agent then attempts to install the update and sends a versioncontrol response to the message broker (e.g., whether the update wassuccessfully installed or not, etc.). In some examples, the versioncontrol response may contain other statistics, such as install timeand/or available space for future updates, etc.

As used herein, DCNs include non-virtualized physical hosts, virtualmachines (VM), containers that run on top of a host operating systemwithout the need for a hypervisor or separate operating system, andhypervisor kernel network interface modules. In some examples, a DCN maybe referred to as a data computer end node or as an addressable node.VMs operate with their own guest operating system on a host usingresources of the host virtualized by virtualization software (e.g., ahypervisor, virtual machine monitor, etc.). Numerous VMs can run on asingle computer of processor system in a logically separate manner fromone another. A VM can execute instances of applications or programsseparate from application/program instances executed by other VMs on thesame computer. In examples disclosed herein, containers are constructsthat run on top of a host operating system without the need for ahypervisor or a separate guest operating system. Like VMs, containersare also logically separate from one another, and numerous containerscan run on a single computer of processor system. Also like VMs, acontainer can execute instances of applications or programs separatefrom application/program instances executed by the other containers onthe same computer or processor system. In some examples, the hostoperating system uses name spaces to isolate the containers from eachother and therefore provides operating-system level segregation of thedifferent groups of applications that operate within differentcontainers. This segregation is akin to the VM segregation that isoffered in hypervisor-virtualized environments that virtualize systemhardware, and thus can be viewed as a form of virtualization thatisolates different groups of applications that operate in differentcontainers. In some examples, such containers are more lightweight thanVMs. In some examples disclosed herein, a hypervisor kernel networkinterface module is a non-VM DCN that includes a network stack with ahypervisor kernel network interface and receive/transmit threads.Example of a hypervisor kernel network interface module include thevmknic module that is part of the ESXi™ hypervisor provided by VMware,Inc.

As used herein, the term “deployment environment” refers to a computingenvironment in a cloud platform provider (also referred to herein as a“cloud provider”). For example, separate deployment environments may beused for development, testing, staging, and/or production. An examplecloud provider can have one or multiple deployment environments.

FIG. 1 is a block diagram of an example system 100 to manageapplications installed on target DCNs 102 in a deployment environment104. The target DCNs 102 may include non-virmalized physical hosts,virtual machines (VM), containers (e.g., Docker® containers, etc.),hypervisor kernel network interface modules, etc. The example system 100includes an example message broker 106 and an example collector bank108. The example message broker 106 and the example collector bank 108may be used to retrieve information (e.g., version, install space,installation metrics, etc.) about applications and/or may be used toinstall updates to applications installed on target DCNs 102 deployed inthe deployment environment 104. The system 100 of the illustratedexample also includes an example application repository 110 to maintainapplication updates and patches, an example version control database 112to store application information retrieved from the target DCNs 102, andan example user interface (UI) 114 to allow an administrator 116 and/ora developer 118 to create version control tasks and view informationstored in the example version control database 112.

Because the example deployment environment 104 is dynamic (e.g., thetarget DCNs 102 are being deployed and/or terminated as necessary tosuit the needs of the example deployment environment, etc.) and/or theexample deployment environment 104 potentially includes a large numberof example target DCNs 102, the example system 100 allows theadministrator 116 and/or the developer 118 to manage applicationsinstalled on the target DCNs 102 without requiring them to create aseparate version control task for each target DCN 102. Additionally,because the deployment environment 104 may contain different types oftarget DCNs 102 (e.g. non-virtualized physical hosts, VMs, containers,etc.) and/or because different DCNs 102 can use different communicationprotocols, the example system 100 allows the example deploymentenvironment 104 to scale and/or be diverse without increasing complexityfor the administrator 116 and/or the developer 118.

In the illustrated example of FIG. 1, the version control database 112may store information related to applications installed on the targetDCNs 102 in the deployment environment 104. For example, the versioncontrol database 112 may include DCN identifiers (IDs) corresponding tothe target DCNs 102, the applications installed on the target DCNs 102,the versions of the applications installed on the target DCNs 102,historical information regarding past version control tasks and/orversion control responses, and/or other information (e.g., the installtime of the last update, available resources, criticality of the targetDCN 102, etc.) that may be used to manage the applications in thedeployment environment 104, etc. In some examples, the version controldatabase 112 may be any data structure suitable for storing data, suchas a relational database (e.g., a MySQL, database, etc.) or anExtensible Markup Language (XML) file, etc. Example collectors 120 inthe example collector bank 108 store information received from theexample target DCNs 102 in the example version control database 112.

The administrator 116 and/or the developer 118 use the example UI 114 tocreate version control tasks to be executed by one or more target DCNs102. An example version control task includes requesting the version ofone or more applications installed on the target DCNs 102. Anotherexample version control task includes requesting that an applicationupdate be installed on the target DCNs 102. In some examples, whencreating a version control task, the administrator 116 and/or developer118 specifies one or more rules to be used to determine which targetDCNs 102 are to receive the version control task. For example, theadministrator 116 and/or developer 118 may specify an application toupdate, a group of target DCNs 102 to update, and/or a type of targetDCN 102 to update, etc. The example UI 114 may present the informationstored in the example version control database 112 to the administrator116 and/or the developer 118 to facilitate generating the versioncontrol tasks. In some examples, the UI 114 also facilitates theadministrator 116 and/or the developer 118 to generate version controlpolicies. For example, a policy may state that target DCNs 102 that havebeen designated as critical only are to receive critical updates and/orare only to receive updates after a backup target DCN 102 is deployed.

The example message broker 106 maintains an example task queue 122, anexample response queue 124, and example target queues 126. In theillustrated example, the task queue 122, the response queue 124, and thetarget queue(s) 126 operate to manage the flow of the version controltasks and version control responses. In the illustrated example, themessage broker 106 places version control tasks received or retrievedfrom the UI 114 on the task queue 122. In some examples, a collector 120retrieves a version control task from the task queue 122 when thecollector 120 is available to process a version control task.Additionally or alternatively, a collector 120 may signal (e.g., notifythe message broker 106) that it is available, and the message broker 106may send a version control task from the task queue 122 to the availablecollector 120. In some examples, the message broker 106 places newversion control tasks at the end of the task queue 122 so that the taskqueue 122 can provide the version control tasks on a first-in-first-outbasis. In some examples, the message broker 106 assigns correspondingpriority levels (e.g. based on the criticality of the update, etc.) tothe version control tasks. In some such examples, the task queue 122provide version control tasks in order of their assigned priority.

In some examples, the message broker 106 includes a plugin manager whichallows the message broker 106 to be integrated into diverse deploymentenvironments 104. For example, through the plugin manager, communicationcapabilities (e.g., message formats, communication protocols, etc.) canbe added to message broker 106 so the message broker 106 can communicatewith particular target DCNs 106 and/or customized UIs 114. In some suchexamples, the plugin manager provides an interface that allowsadministrators 116 and/or developers 118 to add functionality to themessage broker 106 without modifying the message broker 106 and/orunderstanding the underlying functionality of the message broker 106.

In the illustrated example of FIG. 1, the collectors 120 process theversion control tasks obtained from the task queue 122. The examplecollectors 120 assign routing key(s) to the version control tasks. Therouting key(s) specify which target DCN(s) 102 is/are to receiveparticular version control tasks. In some examples, the particulartarget DCN(s) 102 and/or a particular group of the target DCNs 102 arespecified by the version control task. Additionally or alternatively,the example collectors 120 may assign routing key(s) based on a policydefined by the administrator 116 and/or the developer 118. For example,a policy may specify that, when a collector 120 receives a versioncontrol task requesting that an application be updated, all of thetarget DCN(s) 102 with that application installed are to receive theversion control task. In some examples, the collectors 120 access theversion control database 112 to determine which of the target DCN(s) 102is/are to receive a version control task. In some examples, a collector120 parses the version control task according to particular requirementsof the target DCN(s) 102, in some examples, the collector 120 records inthe version control database 112 that the version control task is to besent to ones of the target DCN(s) 102 associated with the routingkey(s).

The example system 100 may include one or more example collector banks108 to manage corresponding example collectors 120. In some examples,the message broker 106 and the collector bank(s) 108 are loosely coupledin a many-to-many configuration. In such examples, because the messagebroker 106 and the collector bank(s) 108 are loosely coupled, themessage broker 106 and the collector bank(s) 108 asynchronouslycommunicate without knowledge of how recipient will process thecommunications. Being loosely coupled facilitates interchangeability(e.g., the configuration of the message broker 106 and/or the collectorbank(s) 108 can change without affecting how the two communicated witheach other). In such examples, because the message broker 106 and thecollector bank(s) 108 are coupled in a many-to-many configuration, amessage broker 106 may be in communication with multiple collector banks108, and vice versa. In the illustrated example, the collector bank 108dynamically deploys and/or terminated collectors 120 to balance resourceusage (e.g., more collectors 120 require more computing resources, etc.)and task queue length (e.g., more collectors 120 will process the queuesfaster, etc.). In some examples, the collector bank 108 may terminate acollector 120 when the accumulative idle time for the collectors 120 inthe collector bank 108 satisfies (e.g., is greater than or equal to) athreshold for a duration. In such examples, accumulative idle times arecalculated for the collectors 120 in the collector bank 108 because asversion control tasks become available, some collector 120 may remainidle while other collectors 120 process the new version control tasks.So, while any one collector 120 in the collector bank 108 may not remainidle for a long period of time, collectively, collectors 120 may be idleenough to justify terminating one or more collectors 120. Additionallyor alternatively, the example message broker 106 may request that acollector 120 be terminated. For example, the message broker 106 maymake such a request when the task queue 122 and/or the response queue124 remain below a threshold length (or threshold sire) for a thresholdperiod of time (e.g., a threshold duration defined by the administrator116 and/or the developer 118). In some examples, the message broker 106may request that an additional collector 120 be deployed when theaccumulated length of task queue 122 and/or the response queue 124remains above a threshold length (or threshold size) for a thresholdperiod of time (e.g. a threshold duration defined by the administrator116 and/or the developer 118). In some examples, the threshold period oftime is based on, for example, the average time for a collector 120 toprocess a version control task or a version control response and thetime required to deploy or terminate a collector 120.

In the illustrated example of FIG. 1, the collectors 120 send theversion control tasks with routing key(s) to an exchange 128 within themessage broker 106. The example exchange 128 sends (e.g., directly orindirectly) the targeted version control task to one or more targetqueues 126. In some examples, the example exchange 128 places thetargeted version control tasks on the target queue(s) 126 correspondingto the routing key(s) included with the targeted version control tasks.Alternatively, in some examples, the exchange 128 broadcasts thetargeted version control tasks and the target queues 126 etiquette theversion control tasks with the corresponding routing key. In eithercase, enqueuing a version control tasks in association with acorresponding routing key in a target queue 126 facilitatescommunicating the version control tasks to the target DCNs 102 withoutrequiring the collectors 108 to know how to communicate with the targetDCNs 102.

In the illustrated example, the message broker 106 manages the targetqueues 126. In some examples, when a target DCN 102 is added to thedevelopment environment 104, the message broker 106 binds a target queue126 (e.g., instantiates a corresponding target queue 126 and assigns arouting key, etc.) to the newly added target DCN 102. In some examples,when a target DCN 102 is removed from the development environment 104,the message broker 106 unbinds the target queue 126 (e.g., terminatesthe corresponding target queue 126 and unassigns the correspondingrouting key, etc.) associated with the removed DCN 102. In someexamples, the message broker 106 implements the Advanced Message QueuingProtocol (AMQP) (e.g., as implemented by RabbitMQ™ of Pivotal® Software,Inc.) to manager the target queues 126.

The example target DCNs 102 receive version control tasks from theircorresponding target queues 126. In the illustrated example, an exampleagent 130 running on a corresponding target DCN 102 executes the versioncontrol task and generates a version control response to be sent to themessage broker 106. In some examples, the agent 130 sends the versioncontrol response directly to the message broker 106. Alternatively, theexample agent 130 broadcasts the version control response, which is thenreceived by the example message broker 106. If the version control taskrequests the version(s) of application(s) installed on the target DCN102, the example agent 130 collects the requested version information togenerate the version control response. If the version control taskrequests that an application installed on the target DCN 102 be updated,the example agent 130 retrieves the software update from the exampleupdate repository 110, attempts to install the update, and generates theversion control response to report the status of the update (e.g.,whether the update was successful or failed). In such a manner, theexample target DCNs 102 in the example deployment environment 104process version control tasks in parallel, saving time and efficientlymanaging a large number of target DCNs 102. Additionally, because theexample target DCNs 102 send version control responses areasynchronously, the example message broker 106 and/or the examplecollector bank(s) 108 manage resources independently of the exampletarget DCNs 102.

In some examples the agent 130 is idle when there are no version controltasks in the corresponding target queue 126. In such examples, the agent130 wakes up from the idle state when a version control task is enqueuedin the corresponding target queue 126. In some examples, the agent 130pulls the version control task from the corresponding target queue 126.The example agent 130 then executes the version control task, and sendsthe version control response to the message broker 106. Alternatively oradditionally, the example message broker 106 pushes the version controltask to the example agent 130. If another version control task is notpending in the corresponding target queue 130 after the example agentfinishes servicing a current version control task, the example agent 130returns to the idle state. Additionally, in some examples, the agent 130may, from time to time (e.g., at set intervals, at a set time and/ordate, etc.), wake up from the idle state. The example agent 130 thencollects version information of applications installed on thecorresponding target DCN 102 and generates a version control response.In some examples, the agent 130 compares the version information toapplication updates in the repository 110 and includes whether an updateto an application on the target DCN 102 exists within the repository110. In some such examples, the agent 130 also includes whether anupdate is a critical update (e.g., as indicated by informationassociated with the application update). The example agent 130 sends theversion control response to the message broker 106, and then returns tothe idle state. In some examples, the example agent 130 may he scheduledto wake up during historic periods of low activity. In such a manner,the agent 130 proactively reports the application versions to themessage broker 106. Proactively reporting application versionssubstantially reduces or eliminates the need for an administrator 116and/or a developer 118 to generate version control tasks to request suchversion information.

In the illustrated example of FIG. 1, the message broker 106 receivesthe version control responses from the target DCNs 102 and places theversion control responses on the response queue 124. When an examplecollector 120 notifies the example message broker 106 that it isavailable, the example message broker 106 may send a version controlresponse to the available collector 120 via the response queue 124. Theexample collector 120 processes the version control response and updatesthe example version control database 112. If a version control task ison the task queue 122 and a version control response is on the responsequeue 124 when an example collector 120 signals that it is available,the example message broker 106 employs an arbitration policy todetermine which of the version control task or the version controlresponse to send to the available collector 120. For example, thearbitration policy may prioritize the task queue 122 over the responsequeue 124 (or vice versa) based on an objective to communicated versioncontrol tasks to the target DCNs 102 as quickly as possible. As anotherexample, the arbitration policy may select the queue with the longestlength or may alternate between the task queue 122 and the responsequeue 124.

FIG. 2 is a block diagram of example physical machine 206 within thedevelopment environment 104 (FIG. 1 that may execute DCNs (e.g., thetarget DCNs 102 of FIG. 1) to be managed by the system 100 of FIG. 1.The example deployment environment 104 of FIG. 1 may contain one or morephysical machines 206. In the illustrated example, a host 200 managesphysical resources 202 (e.g., processor(s), memory, storage, peripheraldevices, network access, etc.) o the physical machine 206. The examplehost 200 is a native operating system (OS) executing on the physicalresources 202. In some examples, the host 200 executes a manager 204. Insome such examples, the manager 204 is a virtual machine manager (VMM)that creates virtualized hardware (e.g., virtualized storage,virtualized memory, virtualized processors(s), etc.). In some examples,the manager 204 is a container engine that enforces isolation ofphysical resources 202 and isolation of the host 200 to separate nodes206 executing within the same host 200. Isolation means that thecontainer engine manages containers executing instances of applicationsor programs separate from application/program instances executed by theother containers on the same physical machine 206.

In the illustrated example of FIG. 2, the target DCNs 102 execute withinthe environment managed by the manager 204. In some examples, a targetDCN 102 is a VM executing a guest OS (e.g., a Windows operating system,a Linux operating system, etc.) that accesses virtualized hardwarecreated by the manager 204 (e.g., a VMM, etc.). In some such examples,target DCN 102 may execute multiple applications and services.Alternatively, a target DCN 102 is a container. In some such examples,target DCN 102 is isolated (e.g. via name spaces, etc.) by the manager204 (e.g.. a container engine, etc.) from other nodes 206 executing onthe same physical recourses 202. Typically, such container-based targetDCN 102 execute a single application or service and do not execute aguest OS,

In the illustrated example, the nodes 206 have corresponding agents 130to execute version control tasks and/or proactively generate versioncontrol responses. The example agents 130 are configured with thepermissions required to monitor the application versions installed oncorresponding target DCNs 102 and to install application updates to thetarget DCNs 102. The example agents 130 also are configured (e.g.,provided with network location information, login credentials, etc.) toaccess the example update repository 110 (FIG. 1) to retrieveapplication updates. In some examples, the agents 130 execute directlyon the node 206 (e.g., when the node 206 is a VM or non-virtualizedphysical machine, etc.). In some examples, the agents 130 execute aspart of the manager 204 (e.g., when the node 206 is a container, etc.).In some examples, when an agent 130 is installed on a node 206, theagent 130 broadcasts a version control response including the version(s)of application(s) installed on the node 206 and/or identity information(e.g., network address, communication protocol, node type, etc.). Inthis manner, the example collectors 120 (FIG. 1) process the versioncontrol response to add the example node 206 to the example versioncontrol database 112 (FIG. 1).

While an example manner of implementing the system 100 of FIG. 1 isillustrated in FIGS. 1 and/or 2, one or more of the elements, processesand/or devices illustrated in FIGS. 1 and/or 2 may be combined, divided,re-arranged, omitted, eliminated and/or implemented in any other way.Further, the example message broker 106, the example collector bank 108,the example UI 114, the example agent 130, the example target nodes 102,the example host 200, the example manager 204, and/or, more generally,the example system 100 of FIG. 1 may be implemented by hardware,software, firmware and/or any combination of hardware, software and/orfirmware. Thus, for example, any of the example message broker 106, theexample collector bank 108, the example UI 114, the example agent 130,the example target nodes 102, the example host 200, the example manager204, and/or, more generally, the example system 100 of FIG. 1 could beimplemented by one or more analog or digital circuit(s), logic circuits,programmable processor(s), application specific integrated circuit(s)(ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)). When reading any of theapparatus or system claims of this patent to cover a purely softwareand/or firmware implementation, at least one of the example messagebroker 106, the example collector bank 108, the example UI 114, and/orthe example agent 130, the example target nodes 102, the example host200, the example manager 204, is/are hereby expressly defined to includea tangible computer readable storage device or storage disk such as amemory, a digital versatile disk (DVD), a compact disk (CD), a Blu-raydisk, etc, storing the software and/or firmware. Further still, theexample system 100 of FIG. 1 may include one or more elements, processesand/or devices in addition to, or instead of, those illustrated in FIGS.1 and/or 2, and/or may include more than one of any or all of theillustrated elements, processes and devices.

A flowchart representative of example machine readable instructions forimplementing the example system 100 of FIG. 1 is shown in FIG. 3.Flowcharts representative of example machine readable instructions forimplementing the example message broker 106 of FIG. 1 are shown in FIGS.4 and/or 6. A flowchart representative of example machine readableinstructions for implementing the example collectors 120 of FIG. 1 isshown in FIG. 5. A flowchart representative of example machine readableinstructions for implementing the example agent 130 of FIG. 1 is shownin FIG. 7. In these examples, the machine readable instructions compriseone or more programs for execution by a processor such as the processor812 shown in the example processor platform 800 discussed below inconnection with FIG. 8. The program(s) may be embodied in softwarestored on a tangible computer readable storage medium such as a CD-ROM,a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-raydisk, or a memory associated with the processor 812, but the entirety ofthe program(s) and/or parts thereof could alternatively be executed by adevice other than the processor 812 and/or embodied in firmware ordedicated hardware. Further, although the example programs are describedwith reference to the flowcharts illustrated in FIGS. 3, 4, 5, 6 and/or7, many other methods of implementing the example system 100, theexample message broker 106, the example agents 130, and/or the examplecollectors 120 may alternatively be used. For example, the order ofexecution of the blocks may be changed, and/or some of the blocksdescribed may be changed, eliminated, or combined.

As mentioned above, the example processes of FIGS. 3, 4, 5, 6 and/or 7may be implemented using coded instructions (e.g., computer and/ormachine readable instructions) stored on a tangible computer readablestorage medium such as a hard disk drive, a flash memory, a read-onlymemory (ROM), a compact disk (CD), a digital versatile disk (DVD), acache, a random-access memory (RAM) and/or any other storage device orstorage disk in which information is stored for any duration (e.g., forextended time periods, permanently, for brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm tangible computer readable storage medium is expressly defined toinclude any type of computer readable storage device and/or storage diskand to exclude propagating signals and to exclude transmission media. Asused herein, “tangible computer readable storage medium” and “tangiblemachine readable storage medium” are used interchangeably. Additionallyor alternatively, the example processes of FIGS. 3, 4, 5, 6 and/or 7 maybe implemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a non-transitory computer and/ormachine readable medium such as a hard disk drive, a flash memory, aread-only memory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device or storage disk inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information). As used herein, the termnon-transitory computer readable medium is expressly defined to includeany type of computer readable storage device and/or storage disk and toexclude propagating signals and to exclude transmission media. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended.

FIG. 3 is a flowchart representative of example machine readableinstructions 300 which may be executed to implement the example system100 of FIG. 1 to manage updates of applications installed on target DCNs102 (FIG. 1) in the example deployment environment 104 (FIG. 1).Initially, at block 302, the example message broker 106 manages queues(e.g., the example task queue 122, the example response queue 124,and/or the example target queues 126 of FIG. 1). For example, themessage broker 106 of FIG. 1 maintains the example task queue 122 tomanage version control tasks between the example UI 114 (FIG. 1) and theexample collectors 120 (FIG. 1). The example message broker 106 alsomaintains the example response queue to manage version control responsesbetween the example agents 130 (FIG. 1) installed on the example DCNs102 and the example collectors 120. The example message broker 106maintains the example target queues 126 to manage targeted versioncontrol tasks between the example collectors 120 and the example DCNs102. An example process that may be used to implement block 302 isdescribed below in connection with FIG. 4.

At block 304, the example collector bank 108 handles version controltasks and version control responses. For example, the example collectors120 in the example collector bank 108 of FIG. 1 process version controltasks, via the example task queue 122, to assign routing keys to theversion control tasks. The routing keys assigned by the examplecollectors 120 correspond to target DCNs 102 that are to execute theversion control task. In some examples, the collectors 120 parse theversion control tasks according to the particular requirements of thetarget DCN(s) 102. The example collectors 120 process version controlresponses, via the example response queue 124, to update the exampleversion control database 112 (FIG. 1). An example process that may beused to implement block 304 is described below in connection with FIG.5.

At block 306, the example message broker 106 may request to add orremove a collector 120 to the collector bank 108. In some examples, asdescribed above, whether to request a change in the number of collectors120 in the collector bank 108 is based on the lengths (or sizes) of thetask queue 124 and the response queue 122. An example process that maybe used to implement block 306 is described below in connection withFIG. 6. The example program 300 then ends.

FIG. 4 is a flowchart representative of example machine readableinstructions 302 which may be executed to implement the example messagebroker 106 of FIG. 1 to manage the flow of messages (e.g., versioncontrol tasks and/or version control responses, etc.) between theexample UI 114 (FIG. 1), the example collectors 120 (FIG. 1) and/or theexample target DCNs 102 (FIG. 1). Initially, at block 400, the examplemessage broker 106 determines whether a version control task has beenreceived from the UI 114. If the example message broker 106 has receivesa version control task, program control advances to block 402.Otherwise, if the example message broker 106 has not received a versioncontrol task, program control returns to block 400. At block 402, theexample message broker 106 places the version control task on theexample task queue 122 (FIG. 1). In some examples, the message broker106 places the version control task at the end of the task queue 122.Alternatively, when the example task queue 122 is organized by priority,the example message broker 106 may place the version control task inpriority order on the task queue 122.

At block 404, the example message broker 106 determines whether anexample collector 120 in example the collector bank 108 (FIG. 1) isavailable. In some examples, a collector 120 will signal (e.g., send amessage to the message broker, broadcast a message, etc.) when it isavailable to process a version control task or version control response.If an example collector 120 is available, program control advances toblock 406. Otherwise, if an example collector 120 is not available,program control returns to block 404. At block 406, the example messagebroker 106 sends a version control task on the example task queue 122 tothe available example collector 120. At block 408, the example exchange128 (FIG. 1) of the example message broker 106 determines whether atargeted version control task has been received from one of the examplecollectors 120 in the example collector bank 108. If a targeted versioncontrol task has been received, program control advances to block 410.Otherwise, if a targeted version control task has not been received,program control returns to block 408.

At block 410, the exchange 128 sends (e.g., directly or indirectly) theversion control task to example target queue(s) 126 of the exampletarget DCN(s) 102. In some examples, the exchange 128 broadcasts thetarget version control task to be selectively enqueued by the exampletarget queue(s) 126 corresponding to one or more routing key(s) assignedto the version control task. At block 414, the example message broker106 determines whether a version control response has been received froma target DCN 102. If the example message broker 106 has received aversion control response, program control advances to block 416.Otherwise, if the example message broker 106 has not received a versioncontrol response, program control returns to block 414. At block 416,the example message broker 106 places the version control response onthe example response queue 124.

At block 418, the example message broker 106 determines whether anexample collector 120 in the example collector bank 108 is available. Ifa collector 120 is available, program control advances to block 420.Otherwise, if a collector 120 is not available, program control returnsto block 418. At block 420, the example message broker 106 sends theversion control response at the front of the example response queue 124to the available example collector 120 to be processed as described inconnection with FIG. 5 below. The example program 302 then ends.

FIG. 5 is a flowchart representative of example machine readableinstructions 304 that may be executed to implement the examplecollectors 120 of FIG. 1 to process version control tasks and versioncontrol responses from the example message broker 106 (FIG. 1).Initially, at block 500, the example collector 120 signals to theexample message broker 106 that it is available. At block 502, theexample collector determines whether a message (e.g., a version controltask or a version control response, etc.) has been received from theexample message broker 106 in response to signaling that it is ready atblock 500. If a message has been received, program control advances toblock 504. Otherwise, if a message has not been received, programcontrol returns to block 502.

At block 504, the example controller 120 determines whether the receivedmessage is a version control task. If the message is a version controltask, program control advances to block 506. Otherwise, if the messageis not a version control task, program control advances to block 512. Atblock 506, the example collector determines which of the target DCN(s)102 (FIG. 1) is/are to perform the version control task. In someexamples, the collector 120 determines which of the target DCN(s) 102is/are to perform the version control task based on a rule included inthe version control task. For example, a version control task mayinclude a rule that states that all target DCNs 102 with MySQL 5.5installed are to update to MySQL 5.6, and as such, the collector 120 isto determine which of the target DCNs 102 in the deployment environmenthave MySQL 5.5. As another example, the a version control task mayinclude a rule that states that one or more of the target DCNs 102 in acertain group (e.g., one or more target DCNs 102 defined by anadministrator 116 and/or a developer 118 to be managed together, etc.)are to report the version numbers of the MySQL application installed onDCNs 102 in the group. Additionally or alternatively, in some examples,the administrator 116 and/or the developer 118 may define general rulesand/or policies (e.g., via the UI 114) that define which of the targetDCNs 102 are to execute which version control tasks. For example, a rulemay state that if the version control task identifies an update ascritical, all of the target DCNs 102 with that application installed areto execute that version control task. As another example, a rule maystate that all DCNs 102 in the deployment environment 104 (FIG. 1) areto execute version control tasks that request application versionnumbers In some examples, the collector 120 accesses the version controldatabase 112 (FIG. 1) to determine which of the example target DCN(s)102 satisfy the rule.

At block 508, the example collector 120 appends one or more routingkey(s) corresponding to the example target DCN(s) 102 determined atblock 506 to the version control task received at block 502. On someexamples, the version control database 112 stores the routing keys to beretrieved by the collector 120. In some examples, the collector bank 108may maintain a list of routing keys corresponding to the target DCNs 102in the deployment environment 104 for use by the message broker 106 toroute the version control task received at block 502 to the exampletarget DCN(s) 102 determined at block 506. At block 510, the collector120 sends the targeted version control task to the message broker 106.Program control then advances to block 516.

At block 512, the example collector 120 determines whether the messagereceived at block 502 is a version control response. If the message is aversion control response, program control advances to block 514.Otherwise, if the message is not a version control response, programcontrol advances to block 516. At block 514, the example collector 120stores the version control response in the example version controldatabase 114. For example, the collector 120 stores the version controlresponse in association with the example target DCN 102 that sent theversion control response. Program control then advances to block 516. Atblock 516, the example collector 120 determines whether it has receiveinstructions from the example collector bank 108 to shutdown. If theexample collector 120 has not receive instructions to shutdown, programcontrol returns to block 500. Otherwise, if the example collector 120has received instructions to shutdown, the example program 304 ends.

FIG. 6 is a flowchart representative of example machine readableinstructions 306 that may be executed to implement the example messagebroker 106 of FIG. 1 to request that the collector bank 108 (FIG. 1)deploy an addition collector 120 (FIG. 1) or terminate an existingcollector 120. Initially, at block 600, the example message broker 106monitors the example task queue 122 (FIG. 1) and the example responsequeue 124 (FIG. 1). At block 602, the example message broker 106determines whether a collector 120 should be terminated. In someexamples, the message broker 106 determines that a collector 120 shouldbe terminated if the accumulative length of the task queue 122 and theresponse queue 124 is below a minimum activity threshold for a setperiod of time (e.g., one computer cycle, ten computer cycles, onehundred computer cycles, one millisecond, ten milliseconds, etc.). Insome examples, the example message broker 106 determines that an examplecollector 120 should be terminated if, when an example collector 120signals that it is available, the example task queue 122 and the exampleresponse queue 124 are empty. If the example message broker 106determines that an example collector 120 should be terminated, programcontrol advances to block 604. Otherwise, if the example message broker106 does not determine that an example collector 120 should beterminated, program control advances to block 606. At block 604, theexample message broker 106 requests termination of one of the examplecollectors 120. For example, the message broker 106 sends a request tothe example collector bank 108 to terminate a collector 120.

At block 606, the example message broker 106 determines whether anadditional collector 120 should be deployed. In some examples, theexample message broker 106 determines that an additional collector 120should be deployed if either the task queue 122 or the response queueare full 124, or exceed a threshold queue length. In some examples, themessage broker 106 determines that an additional collector 120 should bedeployed if the accumulative lengths of the task queue 122 and theresponse queue 124 are above an activity threshold for a set period oftime (e.g., a threshold duration). If the example message broker 106determines that an additional collector 120 should be deployed, programcontrol advances to block 608. Otherwise, if the example message broker106 does not determine that an addition collector 120 should bedeployed, program control advances to block 610. At block 608, theexample message broker 106 requests deployment of an additionalcollector 120. For example, the example message broker 106 sends arequest to the example collector bank 108 to deploy an additionalcollector 120. At block 610, the example message broker 106 determineswhether to continue monitoring the example task queue 122 and theexample response queue 124. If the message broker 106 is to continuemonitoring the task queue 122 and the response queue 124, programcontrol returns to block 600. Otherwise, if the message broker 106 isnot to continue monitoring the task queue 122 and the response queue124, the example program 306 ends.

FIG. 7 is a flowchart representative of example machine readableinstructions 700 that may be executed to implement the example agents130 of FIG. 1 to proactively send version control responses to themessage broker 106 of FIG. 1. Initially, at block 702, the agent 130determines, from time to time, whether it is to wake up from an idlestate. The example agent 130 goes into an idle state when there are noversion control tasks in the corresponding target queue 126 (FIG. 1).The example administrator 116 and/or example developer 118 (FIG. 1)schedule a time for the example agent 130 to wake up from the idlestate. For example, the agent 130 may be scheduled to proactively checkfor application updates every Monday morning at 12:00am. If the agent130 determines it is to wake up from an idle state, program controladvances to block 704. Otherwise, if the agent 130 determines it is notto wake up from an idle state, program control returns to block 702.

At block 704, the example agent 130 collects version information ofapplications installed on the corresponding target DCN 102. At block706, the example agent 130 determines suggested and/or critical updatesin the repository 110 for application(s) installed on the correspondingtarget DCN 102. The example agent 130 suggests updating any applicationinstalled on a corresponding target DCN 102 that has an update in therepository 110 In some examples, to determine whether there is anapplication update, the agent 130 requests version information ofupdates in the repository 110 corresponding to the applicationsinstalled on the target DCN 102. In some such examples, the agent 103receives an indicated from the repository that a particular applicationupdate is critical. At block 708, the example agent 130 sends aproactive version control message to the example message broker 106including the version control information collected at block 704, andthe suggested and/or critical updates determined at block 706. Theexample proactive version control message is treated as a versioncontrol response by the example message broker 104 and the examplecollector 120. At block 710, the example agent 130 determines whether tocontinue to proactively monitor for application updates. If the exampleagent 130 is to continue to proactively monitor for application updates,program control advances to block 712. Otherwise, if the example agent130 is not to continue proactively monitoring for application updates,program 700 ends. At block 712, the example agent 130 goes into the idlestate until it is to wake up (at block 702).

FIG. 8 is a block diagram of an example processor platform 800structured to execute the instructions of FIGS. 3, 4, 5. 6, and/or 7 toimplement the system 100 of FIG. 1. The processor platform 800 can be,for example, a server, a personal computer, a workstation, or any othertype of computing device.

The processor platform 800 of the illustrated example includes aprocessor 812. The processor 812 of the illustrated example is hardware.For example, the processor 812 can be implemented by one or moreintegrated circuits, logic circuits, microprocessors or controllers fromany desired family or manufacturer. In the illustrated example, theprocessor 812 includes an example message broker 106, an examplecollector bank 108, and an example collector 120. The example messagebroker 106, an example collector bank 108, and an example collector 120may implemented by one more processors 812 on one or more processorplatforms 800. For example, the example message broker 106, an examplecollector bank 108, and an example collector 120 may implemented onseparate processor platforms 800 within a networked environment.

The processor 812 of the illustrated example includes a local memory 813(e.g., a cache). The processor 812 of the illustrated example is incommunication with a main memory including a volatile memory 814 and anon-volatile memory 816 via a bus 818. The volatile memory 814 may beimplemented by Synchronous Dynamic Random Access Memory (SDRAM), DynamicRandom Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM)and/or any other type of random access memory device. The non-volatilememory 816 may be implemented by flash memory and/or any other desiredtype of memory device. Access to the main memory 814, 816 is controlledby a memory controller.

The processor platform 800 of the illustrated example also includes aninterface circuit 820. The interface circuit 820 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 822 are connectedto the interface circuit 820. The input device(s) 822 permit(s) a userto enter data and commands into the processor 812. The input device(s)can be implemented by, for example, an audio sensor, a microphone, acamera (still or video), a keyboard, a button, a mouse, a touchscreen, atrack-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 824 are also connected to the interfacecircuit 820 of the illustrated example. The output devices 824 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay, a cathode ray tube display (CRT), a touchscreen, a tactileoutput device, a printer and/or speakers). The interface circuit 820 ofthe illustrated example, thus, typically includes a graphics drivercard, a graphics driver chip or a graphics driver processor.

The interface circuit 820 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodern and/or network interface card to facilitate exchange of data withexternal machines (e.g., computing devices of any kind) via a network826 (e.g., an Ethernet connection, a digital subscriber line (DSL), atelephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 800 of the illustrated example also includes oneor more mass storage devices 828 for storing software and/or data.Examples of such mass storage devices 828 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and digital versatile disk (DVD) drives.

The coded instructions 832 of FIGS. 3, 4, 5, 6, and/or 7 may be storedin the mass storage device 828, in the volatile memory 814, in thenon-volatile memory 816, and/or on a removable tangible computerreadable storage medium such as a CD or DVD.

FIG. 9 is an example performance comparison graph 900 depicting aperformance, of the system 100 of FIG. 1 for determining versions ofapplications executing in a deployment environment (e.g., the deploymentenvironment 104 of FIG. 1) relative to a virtual machine configurationmanager. The example performance comparison graph 900 depicts an exampletime 902 (in seconds) required for a prior virtual machine configurationmanager to assess the version information of applications installed onDCNs in a deployment environment. A prior virtual machine configurationmanager uses Secure Shell (SSH) in a loop and/or multithreading tocommunicate to DCNs. However, in a dynamic and scaling environment,using a prior virtual machine configuration manager is time and resourceintensive. The example performance comparison graph 900 also depicts anexample time 904 to assess DCNs in a similar deployment environment. Asillustrated in FIG. 9, the example time 904 for the system 100 to assessthe DCNs in the deployment environment is less than the example time 902for the prior virtual machine configuration manager to assess the DCNsin the deployment environment.

From the foregoing, it will be appreciate that examples disclosed hereinfacilitate managing application updates in a dynamic cloud environmentby allowing administrators and/or developers to efficiently managingapplication updates for a large number of data compute nodes. Moreover,because the examples disclosed herein facilitate tasks and responses tobe processed in parallel, a large number of data computer nodes can bemanaged while achieving better performance (e.g., less computer cycles,less memory, etc.) and faster response times. In addition, it will beappreciate that examples disclosed herein dynamically respond toprocessing requirements, thus saving computing resources.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

What is claimed is:
 1. A method to manage application updates in a cloudenvironment, comprising: determining that a collector in a collectorbank is available to process a task, the task to at least one of requestan application version or request an application update; sending thetask from a task queue to the collector to determine which compute nodeis to execute the task; enqueuing the task on a target queue based on arouting key assigned to the task by the collector, the routing key tospecify the compute node to execute the task; and sending the task tothe compute node associated with the target compute node queue.
 2. Amethod as defined in claim I, wherein the collector is to determinewhich compute node is to execute the task based on applicationsinstalled on the compute nodes the cloud environment.
 3. A method asdefined in claim 1, further comprising when a size of the task queue isgreater than a threshold size for a threshold duration, sending arequest to the collector bank to add an additional collector to thecollector bank.
 4. A method as defined in claim 1, further comprisingwhen a size of the task queue is less than a threshold size for athreshold duration, sending a request to the collector bank to terminatean existing collector in the collector bank.
 5. A method as defined inclaim 1, further comprising: determining the availability of thecollector in the collector bank to process a response received from thecompute node, the response to indicate a result of the task; and sendingthe response from a response queue to the collector, the collector toprocess the response to update a version control database based oninformation in the response.
 6. A method as defined in claim 5, furthercomprising when a combination of a size of the task queue and a size ofthe response queue is greater than a threshold for a period of time,sending a request to the collector network to add an additionalcollector to the collector network.
 7. A method as defined in claim 5,further comprising when a combination of a size of the task queue and asize of the response queue is less than a threshold for a period oftime, sending a request to the collector network to terminate anexisting collector in the collector network.
 8. A tangible computerreadable storage Medium comprising instructions which, when executed,cause a machine to at least: determine that a collector in a collectorbank is available to process a task, the task to at least one of requestan application version or request an application update; send the taskfrom a task queue to the collector; enqueue the task on a target queuebased on a routing key assigned to the task by the collector, therouting key to specify the compute node to execute the task; and sendthe task to the compute node associated with the target compute nodequeue.
 9. A tangible computer readable storage medium as defined inclaim 8, wherein the collector is to determine which compute node is toexecute the task based on applications installed on the compute nodesthe cloud environment
 10. A tangible computer readable storage medium asdefined in claim 8, wherein the instructions, when executed, furthercause the machine to send a request to the collector bank to add anadditional collector to the collector network when a size of the taskqueue is greater than a threshold size for a threshold duration.
 11. Atangible computer readable storage medium as defined in claim 8, whereinthe instructions, when executed, further cause the machine to send arequest to the collector network to terminate an existing collector inthe collector network when a size of the task queue is less than athreshold size for a threshold duration.
 12. A tangible computerreadable storage medium as defined in claim 8, further comprisinginstructions which, when executed, further cause the machine to:determine the availability of a collector in the collector bank toprocess a response received from the compute node, the response toindicate a result of the task; and send the response from a responsequeue to the available collector, the available collector to process theresponse to update a version control database based on information inthe response.
 13. A tangible computer readable storage medium as definedin claim 12, wherein the instructions, when executed, further cause themachine to send a request to the collector bank to add an additionalcollector to the collector bank when a combination of a size of the taskqueue and a size of the response queue is greater than a threshold sizefor a threshold duration.
 14. A tangible computer readable storagemedium as defined in claim 12, further comprising when a combination ofa size of the task queue and a size of the response queue is less thansize for a threshold duration, instructions cause the machine to send arequest to the collector network to terminate an existing collector inthe collector network.
 15. A system to manage application updates in acloud environment, comprising: a collector to assign a routing key to aversion control task based on a compute node that is to execute theversion control task; an agent installed on the compute node to executethe version control task, the agent to generate a version controlresponse after at least one of (a) executing the version control task,or (b) proactively comparing a version of an application executing onthe compute node to a version of the application in an applicationrepository; and a message broker to manage a task queue, a respondqueue, and a target queue, the message broker to send the versioncontrol task from the task queue to the collector, the message broker toenqueue on the target compute node queue the version control task basedon the routing key assigned by the collector, and the collector toenqueue on the response queue the version control response received fromthe compute node.
 16. A system as defined in claim 15, wherein thecollector is to notify the message broker when the collector isavailable to process a version control task.
 17. A system as defined inclaim 16, wherein the message broker is to send the version control taskfrom the task queue to the collector in response to being notified bythe collector.
 18. A system as defined in claim 15, wherein the messagebroker is to send the version control response from the response queueto the collector.
 19. A system as defined in claim 15, furthercomprising a collector bank to manage the collector, the message brokerto at least one of deploy an additional collector or terminate anexisting collector.
 20. A system as defined in claim 19, wherein themessage broker is to send a request to the collector bank to deploy theadditional collector when a length of the task queue satisfies athreshold size for a threshold duration.